Network-based applications often make use of many different technologies, object models, and programming languages, from simple Perl scripts and standalone applications implemented in C++ or Java™, to sophisticated applications running on J2EE application servers. In the past, access security was the responsibility of each application, requiring users to employ different user names and passwords for different applications. As users required access to increasing numbers of applications of all types, single sign-on (SSO) mechanisms were developed to standardize access security protocols and form application domains whereby users are given access to applications within the domain without having to separately sign on to each application. To accomplish this, all security algorithms are typically found in a single SSO server which acts as the only authentication point for a defined domain. Thus, a user signs on and is authenticated only once, and thereafter may securely interact with many different elements within a given domain. This is typically done by generating an SSO token for the user after the user is first authenticated, providing the token to the user, and thereafter having the user pass the token to other SSO applications which validate the token with the SSO server.
Unfortunately, not all applications are SSO-compliant. To remedy this, non-SSO-compliant applications may be modified internally to implement SSO mechanisms. However, such applications would need to be modified each time there is a change to the SSO protocol at the SSO server level. Enabling non-SSO-compliant applications to work within an SSO framework without requiring that the applications be modified internally to implement SSO mechanisms would therefore be advantageous.